|Diverse information|Vad är god programmeringsmetodik?|
Alla programmeringsprojekt börjar med att någon får en idé. Hur denna idé fås varierar naturligtvis - den kanske kommer när du ligger och sover, eller när du är på väg till bussen - egentligen är det inte så viktigt hur du fått din idé, det viktiga är ju att du fått den. Ett sätt att ta fram goda idéer är att samlas några stycken kompisar och spåna kring något ämne, samtidigt som någon antecknar eller spelar in på kasettband.
Ett datorprogram används oftast för att lösa ett problem eller för att underlätta ett arbete på något sätt. I denna fas av utvecklingsarbetet kontrolleras om idén är bra eller dålig - dvs om den är lämpad att bli ett datorprogram. Det kanske är bättre att köpa ett redan färdigt program (om det finns) som löser uppgiften. En analys bör göras för att vara säker på att det system du utvecklar är det som din kund tänkt sig. Ofta är det ju så att du inte kommit på programidén själv, utan någon annan vill ha din hjälp att framställa ett program som han(hon tror sig behöva.
En analys görs för att reda ut vad som ska konstrueras innan du börjar fundera på hur du ska konstruera det. Analysen används också för att hitta oklarheter och fel så tidigt som möjligt i programutvecklingen.
Några saker att tänka på vid analysen är följande:
Under analysfasen ska följande dokument tas fram:
En kravspecifikation innehåller ramar för tid, pris mm. Den innehåller även ett antal sk "skall -krav", dvs sånt som programmet ska innehålla. Det kan också finnas sk "bär - krav". Dessa är krav som bör finnas med om det går att ordna, beroende på övriga givna förutsättningar (tid, pris bl a). Specifikationen ska också ange vilka begränsningar systemet har.
En specifikation ska tala om vad systemet ska göra, men inte hur. In- och utdatas utseende ska noga specifieras (dvs datatyper, filer mm, som används).
Tisplanen innehåller en beskrivning an när arbetet ska utföras och när de olika momenten ska vara klara. Det här är ofta mycket svårt att beräkna, så du får vara beredd på att tidplanen måste ändras, revideras, under projektets gång. Saker tar ofta längre tid än du från början tror. Multiplicera gärna med faktorn p (3,1415…) för att vara någotsånär på den säkra sidan!!!
Användarbeskrivningen innehåller information om hur programmet uppför sig gentemot en användare. Detta innebär att du måste göra klart för dig hur alla skärmbilder, dialogrutor mm ska se ut och fungera.
Det är mycket viktigt att innehållet i alla dessa dokument diskuteras med kunden innan du går vidare med arbetet.
Börja med en övergripande design, även kallat systemering. Dela sedan in systemet i flera mindre delar, sk moduler. I detta skede ska du bestämma hur kundens önskemål ska uppfyllas. Försök att identifiera generella programfunktioner.
När modulindelningen ska göras behöver ett projekt ofta ha ett antal personer med specialkompetens inom just det området, tex bildbehandling, animering eller beräkning. Det betyder att det är en stor fördel om man hjälps åt - åtminstone om det är ett stort projekt. De projekt vi ska genomföra är normalt inte så stora att det behövs flera personer. Vid moduldesignen måste du bestämma hur programmets interna modulkommunikation ska se ut - definiera parametrar, globala variabler mm.
Under designfasen ska en designbeskrivning tas fram. Där ska det framgå hur modulindelningen är gjord och hur modulerna samverkar med varandra. Du ska också göra en dokumentöversikt för att hålla reda på alla ingående dokument. Det blir en del pappersjobb!
I designfasen utvecklas de algoritmer som avgör programmets funktion och prestanda. Programmets övergripande funktion bestäms. Det finns en hel del olika designmetoder utarbetade. En kallas för JSP-metoden och går ut på att du ritar en del figurer och symboler som på ett speciellt sätt beskriver funktionen. En annan vanlig metod är att använsda sig av flödesschemor.
Om designfasen är ordentligt genomförd är kodningsfasen ungefär att jämföra med att skriva in en text i ett datorprogram - det ska alltså gå ganska smidigt. Det kan förvisso medföra en del problem, men ju bättre du känner till det valda programspråkets miljö och syntax, desto enklare är det.
I princip behöver du inte bestämma programspråk förrän i detta läge. Alla moduler i ett och samma projekt behöver inte ens skrivas i samma språk. Ibland måste vissa rutiner skrivas på ett sådant sätt att vissa programmeringsspråk inte är användbara.
Om du vill göra program som är snabba kan du välja tex C eller assembler, men om du anser att användarvänligheten är viktigare väljer du kanske hellre Visual Basic.
De flesta fel som finns i existerande program har uppkommit vis designfasen och inte vid kodningen. Det betyder alltså att om du har tänkt fel vid designen blir det fel i programfunktionen även om du har skrivit koden korrekt.
Vid kodningen börjar du lämpligen med att skriva pseudokod. Detta är en slags beskrivande blandning av text och kod uppställd på samma sätt som den riktiga källkoden senare ställs upp. Pseudokoden utgör alltså en utförlig beskrivning av programmets utseende med loopar, procedur anrop och sekvenser.
Pseudokoden är oftast lättare för en människa att förstå än själva källkoden. Detta gäller främst vid programmering i lågnivåspråk, tex assembler programmering.
Under kodningsfasen tas alltså pseudokod och källkod fram för alla programdelar.
Testning ska alltid utföras fortlöpande under utvecklingsarbetet. Försäkra dig alltid om att de procedurer, funktioner och moduler som ingår lämnar ifrån sig rätt resultat. Det är ibland nödvändigt att skriva extra kodsnuttar för att testa vissa delar av programmets funktion. Det kan också bli nödvändigt att skriva rena testprogram - vissa funktioner kanske inte ens går att testa fullständigt.
Om du väntar ändå tills du skrivit färdigt all kod innan du börjar testa programmet är det stor risk att du kommer att stöta på många fel som kräver åtgärder. Ju mer du tänkt innan du sätter dig vid datorn, desto bättre är det. Vid testningen är det meningen att du ska hitta alla fel (buggar) ditt program innehåller. Det finns så klart olika metoder att utföra ett test på:
Detta innebär att ett antal personer har ett möte där de granskar olika dokument och försöker avgöra om det kommer att fungera.
Programmets körs med kända indata och utdata jämförs med det förväntade resultatet, antingen manuellt eller automatiskt.
När varje programdel har testats för sig ska allting slutligen testas tillsammans. Detta kallas ofta för integrationstest.
I denna fas ska du skriva dokumentet testspecifikation där du skriver hur testerna ska utföras.
Ett datorprogram ska förhoppningsvis användas under ett antal år. Det innebär att den som ska använda ditt program kan komma att behöva en del hjälp en tid efter att han/hon köpt ditt program. Det kan, trots alla ansträngningar att göra ett felfritt program, visa sig att allting i ditt program inte fungerar i alla lägen.
Detta måste du naturligtvis då åtgärda på ett eller annat sätt.
Den första versionen av ett program brukar följas av versionsbeteckningen 1.0. När du fått rapporter om ett antal buggar (felfunktioner) i ditt program kanske du väljer att det är dags att åtgärda dessa och du gör då en ny version som du kallar 1.1. Om du i samma veva lägger till ett antal extra funktioner och finesser i programmet kanske du istället väljer att döpa om den nya versionen till 2.0, eftersom det är relativt stora förändringar som du genomfört. På det här viset fortsätter du i princip att underhålla ditt program under hela dess livstid.
Något du kanske inte tänkt på är att kostnaden för drift/support och underhåll för ett program är den överlägset största posten vid programutvecklingsprojekt av normal kommersiell klass (ca 67%).
En av anledningarna till att du ska skriva en klar och redig kod med erforderliga kommentarer och annan dokumentation är naturligtvis att det underlättar arbetet med programunderhållet. Tänk på att det är mycket sannolikt att det är någon annan än du själv som kommer att jobba med programförändringar och uppdateringar. Det är ju också självklart så att dukan råka ut för att underhålla kod som någon annan programmerare skrivit.
Ytterligare en synvinkel på detta med underhåll och support är vilken hårdvaroplattform programmet är avsett för. Antag att du skrivit ett program avsett att användas i PC-miljö. Kan en användare fortfarande köra programmet efter att denne köpt en ny, modernare dator, eller lagt till något instickskort i sin maskin? Kompatibilitet är med andra ord väldigt viktigt.
Underhåll kan grovt delas in i nedanstående delar:
Den tredje punkten kan tex betyda att koden ska överföras (portas) till att kunna köras på en Apple Macintosh. De flesta av dagens stora programtillverkande företag skriver programversioner både för PC och Macintosh.
Vad är god programkvalitet?